Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add optional support for comments #61

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

TheLocehiliosan
Copy link

While not officially part of the JSON standard, there are many parsers which will accept comments.

This change allows users to set an option which recognizes comments as comments instead of an error.

@epcim
Copy link

epcim commented Oct 16, 2015

Hi, it would be great to add support for comments that do not break the JSON syntax. IE:

{
   "_comment": "comment text goes here...",
   "glossary": {
      "title": "example glossary",
      "GlossDiv": {
         "title": "S",
....
....

See:
http://stackoverflow.com/questions/244777/can-i-use-comments-inside-a-json-file#comment14790821_244858

@TheLocehiliosan
Copy link
Author

The problem with the "_comment": "Comment here", style of comment is that it adds superfluous data which your programs later may have to deal with. For example, you might want to add a comment in a data structure which is expecting a hash of hashes. If one of the values happens to be a string instead of a hash, you could have problems. So you have to "filter out" the "_comment" stuff. :/

It's also problematic to put a comment on the same line as data, or in the middle of a data structure when "adding extra comment data".

As for syntax-highlighting that type of comment, it's probably possible, but what happens if a key "_comment" points to a value which is a larger data structure? Should that whole structure be highlighted as a comment? Maybe it only highlights the rest of that line as a comment? I might see if I can work up something useful that is turned on by setting a variable with the "comment" key to be used. Something like let g:vim_json_comment_key=_comment

@jcristovao
Copy link

Hi @elzr , any possibility of this PR getting merged? I also find it quite useful, and being optional, it does not break 'normal' JSON behaviour.

Thanks

@bmartin-pan
Copy link

Hey @elzr , I agree that this seems perfectly reasonable. Even Douglas Crockford said that using json for configuration files and including comments is reasonable.

Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.

@kevinoid
Copy link

I'm also a fan of this pull request and hope it gets merged in some form.

One suggestion: Support b:vim_json_comments instead of or in addition to g:vim_json_comments for enabling/disabling comment support. That way comment support can be enabled on a per-buffer basis (e.g. using autocmd to enable comments only for JSON files known to allow comments) rather than requiring it to be enabled for all JSON files.

@kevinoid
Copy link

Since this PR doesn't seem to be going anywhere, I decided to package the changes as vim-jsonc using the jsonc filetype to make it easy to use until support is added to vim-json in some form.

@ell1e
Copy link

ell1e commented Mar 4, 2021

How would one change all json files to be treated as jsonc? It would be great if this could just be merged in some way to make it easier to use.

@willeccles
Copy link

willeccles commented Jun 14, 2021

How would one change all json files to be treated as jsonc? It would be great if this could just be merged in some way to make it easier to use.

@ell1e I believe this should do the trick (if you didn't already find the solution):

autocmd BufNewFile,BufRead *.json setl ft=jsonc

@IzhakJakov
Copy link

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants